the PyTypeInfo trait should be unsafe, because otherwise a user can cause UB by mis-implementing it.

I modified the signature of PyTypeInfo::type_object() to return *mut instead of &mut.

👍 for this change.

So... I think this PR is good but the problem is our pair of PyTypeInfo::type_object and PyTypeObject has really complex semantics(I don't remember correctly... but maybe to avoid specialization?).

I'm sorry but I'm going to merge this PR after understanding the problem clearer.

No rush. 👍

I spent some time thinking about PyTypeObject this morning. I experimented with merging PyTypeInfo and PyTypeObject, but it leads to refactorings across the codebase. Probably too big to land in a single PR. I'll share notes about it sometime.

I had some ideas to take this a little further:

• Now type_object() always returns an initialized PyTypeObject.
• type_object() now returns NonNull instead of *mut.
• Removed PyTypeObject::init_type() - it's no longer needed.
• Removed initialize_type<T>() - it's no longer possible to initialize the type object manually other than by calling type_object().
• PyTypeInfo is now unsafe trait
• Also removed use of static mut in all the exceptions.rs macros.

Sorry for the delay with the review..., but now I'm considering fn type_object() -> Pin<&'static ffi::PyTypeObject for this purpose and experimenting it.

Please do experiment with better designs! I'd rather we make these changes once and get them right than break stuff again and again :)

Let me know if you come up with something you prefer and want me to change this PR.

I tried to remove Box::new in create_type_object but this attempt just told me that ffi::PyType_Ready requires type object has a static address 🙄
So now I think the currently implementation is sufficiently good, except some minor things.

I also tried Pin<&'static ffi::PyTypeObject>, but finally I didn't like it since it requires too many pointer conversion.

force-push is my failure... don't mind it.

Thank you!